Introducció: Per a les empreses, el principal repte de la recopilació de dades mai no ha estat simplement la "sincronització", sinó com garantir la precisió, la integritat i la actualitat de les dades en un entorn a gran escala, heterogeni i complex. Aquest article aprofundeix en la pràctica de SUPCON de construir un marc de recopilació de dades a nivell empresarial basat en Apache SeaTunnel, centrant-se en compartir perspectives i solucions específiques en aspectes com la configuració d'alta disponibilitat de clústers, l'optimització del rendiment, els mecanismes de tolerància de errors i el seguiment de la qualitat de les dades. Introducció: Per a les empreses, el principal repte de la recopilació de dades mai no ha estat simplement la "sincronització", sinó com garantir la precisió, la integritat i la actualitat de les dades en un entorn a gran escala, heterogeni i complex. Aquest article aprofundeix en la pràctica de SUPCON de construir un marc de recopilació de dades a nivell empresarial basat en Apache SeaTunnel, centrant-se en compartir perspectives i solucions específiques en aspectes com la configuració d'alta disponibilitat de clústers, l'optimització del rendiment, els mecanismes de tolerància de errors i el seguiment de la qualitat de les dades. Dilema: Arquitectura de col·lecció de silos i alts costos d'operació i manteniment Com a companyia de plataforma d'IA industrial que empodera profundament la indústria de processos, el negoci global de SUPCON s'ha desenvolupat contínuament. Actualment, compta amb gairebé 40 filials globals i serveix a més de 35.000 clients globals. La contínua expansió del negoci ha plantejat requisits més alts per al treball de dades: les dades no només han de ser "calculades ràpidament" sinó també "deparades amb precisió". A aquest efecte, hem construït una plataforma de grans dades separada per a fer front a escenaris complexos. No obstant això, la complexitat de la plataforma mateixa ha augmentat inversament la dificultat de la recollida de dades, el desenvolupament i l'operació i el manteniment, especialment en l'enllaç font de la recollida de dades, on ens enfrontem a re : En el passat, durant molt de temps hem confiat en solucions compostes de múltiples eines (com l'ús de Sqoop per a la sincronització de dades de lot a HDFS, i Maxwell/StreamSets per processar els registres incrementals de la base de dades i escriure'ls a Kafka/Kudu). (1) Complex Architecture with Silos L'absència d'un mecanisme unificat de vigilància i alerta significa que qualsevol anomalia (com retards de sincronització, esgotament de recursos) requereix molta força de treball per a la resolució de problemes i "combat d'incendis", fent difícil garantir l'estabilitat. (2) O&M Black Hole, Constantly Firefighting : En enfrontar-nos a noves fonts de dades (com les bases de dades domèstiques i SAP HANA), hem de trobar solucions d’adaptació en diferents eines o desenvolupar plug-ins de forma independent, cosa que fa impossible respondre ràpidament a les necessitats de negoci. (3) Segmented Capabilities, Difficult to Expand La figura anterior mostra clarament l'ecosistema de recollida anteriorment descentralitzat. Ens vam adonar que aquest model "desorganitzat" s'ha convertit en l'enllaç més vulnerable en el processament de dades. No només no s'ajusta a la velocitat de desenvolupament futur de l'empresa, sinó que també representa amenaces potencials per a la qualitat i la actualitat de les dades. Combatre el dilema: pensaments sobre un marc de col·lecció unificat i selecció de tecnologia Després d’una anàlisi i reflexió en profunditat, hem aclarit els cinc criteris de selecció bàsics per a les noves tecnologies: : Hauria de cobrir plenament tots els tipus de fonts de dades actuals i futures de l'empresa (de MySQL, Oracle, HANA a Kafka, StarRocks, etc.) i donar suport tant a modes de recollida en línia com en temps real, resolt fonamentalment el problema de les piles de tecnologia unificades. (1) Comprehensive Connectivity : El marc en si ha de ser un clúster distribuït altament disponible amb una forta tolerància a errors. Fins i tot si un sol node falla, tot el servei no s'ha d'interrompre i es pot recuperar automàticament, assegurant el funcionament continu de la canonada de recollida de dades. (2) Cluster Stability and High Availability A nivell d'execució de tasques, ha de proporcionar semàntica de processament Exactament una vegada o Almenys una vegada per assegurar que les tasques puguin recuperar-se automàticament de les interrupcions després d'interrupcions anormals, eliminant la duplicació o pèrdua de dades, que és la pedra angular de la qualitat de les dades. (3) Reliable Data Consistency Guarantee La seva arquitectura hauria de donar suport a l'expansió horitzontal, i el rendiment de la sincronització es pot millorar linealment afegint nodes per satisfer les necessitats de creixement de dades portades pel ràpid desenvolupament del negoci. (4) Strong Throughput Performance Ha de proporcionar un mecanisme complet de monitoratge i alerta, que pugui rastrejar indicadors clau com anomalies, retards i rendiment durant la sincronització de dades en temps real, i notificar el personal d'operació i manteniment de manera oportuna, transformant el "foc de lluita" passiu en "alerta primerenca" activa. (5) Observable O&M Experience Basant-nos en aquests cinc criteris, vam dur a terme investigacions en profunditat i proves comparatives sobre solucions mainstream en la indústria. Finalment, Apache SeaTunnel va realitzar excel·lents resultats en totes les dimensions i es va convertir en la nostra solució òptima per trencar el dilema. Our Core Requirements Apache SeaTunnel's Solutions Comprehensive Connectivity It has an extremely rich Connector ecosystem, officially supporting the reading and writing of hundreds of source/destination databases, fully covering all our data types. A single framework can unify offline and real-time collection. Cluster Stability and High Availability The separated architecture of SeaTunnel Engine ensures that even if a single Master or Worker node is abnormal, it will not affect the continuity of collection tasks. Reliable Data Consistency Guarantee It provides a powerful fault tolerance mechanism, supports Exactly-Once semantics, and can realize automatic breakpoint resumption after task abnormalities through the Checkpoint mechanism, ensuring no data loss or duplication. Strong Throughput Performance It has excellent distributed data processing capabilities. Parallelism can be adjusted through simple configuration, easily realizing horizontal expansion. Observable O&M Experience It provides rich monitoring indicators and can be seamlessly integrated with mainstream monitoring and alerting systems such as Prometheus, Grafana, and AlertManager, allowing us to have a clear understanding of the data collection process. Connectivitat integral Té un ecosistema Connector extremadament ric, que oficialment dóna suport a la lectura i escriptura de centenars de bases de dades de font / destinació, cobrint completament tots els nostres tipus de dades. Estabilitat del clúster i alta disponibilitat L'arquitectura separada de SeaTunnel Engine assegura que fins i tot si un sol node mestre o treballador és anormal, no afectarà la continuïtat de les tasques de recollida. Garantia de consistència de dades fiables Proporciona un poderós mecanisme de tolerància a errors, dóna suport a la semàntica Exactly-Once i pot realitzar la reincorporació automàtica del punt de ruptura després de les anomalies de la tasca a través del mecanisme Checkpoint, assegurant que no es perdin dades ni es dupliquin. Un gran rendiment a través Té excel·lents capacitats de processament de dades distribuïdes. El paral·lelisme es pot ajustar mitjançant una configuració simple, realitzant fàcilment l'expansió horitzontal. Experiència O&M Proporciona rics indicadors de monitoratge i es pot integrar sense problemes amb sistemes de monitoratge i alerta com Prometheus, Grafana i AlertManager, permetent-nos tenir una comprensió clara del procés de recollida de dades. Pràctica: plans específics d'implementació i detalls La nostra pràctica amb Apache SeaTunnel és també el camí de creixement del projecte.En les primeres etapes, vam construir basant-nos en Apache SeaTunnel v2.3.5.En aquell moment, per satisfer algunes necessitats específiques (com ara gestionar problemes de sensibilitat de cas de diferents noms de taules de bases de dades o noms de camps), vam dur a terme una mica de treball de desenvolupament secundari. No obstant això, amb el ràpid desenvolupament de la comunitat SeaTunnel, les funcions i els convertidors de la nova versió s'han tornat cada vegada més complets.Quan vam actualitzar amb èxit el clúster a Apache SeaTunnel v2.3.11, ens va sorprendre agradablement trobar que les necessitats que anteriorment requerien desenvolupament personalitzat ara són suportades nativament en la nova versió. Actualment, totes les nostres tasques de sincronització de dades s’implementen basant-se en la versió oficial, aconseguint zero modificacions, la qual cosa redueix molt els nostres costos de manteniment a llarg termini i ens permet gaudir sense problemes de les últimes funcions i millores de rendiment aportades per la comunitat. Els següents són els nostres plans de implementació bàsics basats en la versió v2.3.11, que han estat verificats pel volum de dades de nivell TB en l'entorn de producció i han posat una base sòlida per a l'excel·lent rendiment de 0 fallades des que es va construir el clúster. 1) Planificació del clúster Per garantir l'alta disponibilitat del clúster, es recomana prioritzar la implantació d'un clúster de mode separat. Node CPU Memory Disk JVM Heap Master-01 8C 32G 200G 30G Master-02 8C 32G 200G 30G Worker-01 16C 64G 500G 62G Worker-02 16C 64G 500G 62G Worker-03 16C 64G 500G 62G Màster 01 8C 32G 200 g 30 g Màster 02 8C 32G 200 g 30 g Treballadors-01 16C 64 g 500 g 62g Treballadors 02 16C 64 g 500 g 62g Treballadors-03 16C 64 g 500 g 62g (2) Arxius de configuració de clústers clau This configuration file is mainly used to define the execution behavior, fault tolerance mechanism, and operation and maintenance monitoring settings of jobs. It optimizes performance by enabling class loading caching and dynamic resource allocation, and ensures job fault tolerance and data consistency by configuring S3-based Checkpoints. In addition, it can enable indicator collection, log management, and settings, thereby providing comprehensive support for the stable operation, monitoring, and daily management of jobs. seatunnel.yaml seatunnel: engine: # Class loader cache mode: After enabling, it can significantly improve performance when jobs are frequently started and stopped, reducing class loading overhead. It is recommended to enable it in the production environment. classloader-cache-mode: true # Expiration time of historical job data (unit: minutes): 3 days. Historical information of completed jobs exceeding this time will be automatically cleaned up. history-job-expire-minutes: 4320 # Number of data backups backup-count: 1 # Queue type: Blocking queue queue-type: blockingqueue # Execution information printing interval (seconds): Print job execution information in the log every 60 seconds. print-execution-info-interval: 60 # Job metric information printing interval (seconds): Print detailed metric information in the log every 60 seconds. print-job-metrics-info-interval: 60 slot-service: # Dynamic Slot management: After enabling, the engine will dynamically allocate computing slots based on node resource conditions, improving resource utilization. dynamic-slot: true # Checkpoint configuration. checkpoint: interval: 60000 # Time interval between two Checkpoints, in milliseconds (ms). Here it is 1 minute. timeout: 600000 # Timeout for Checkpoint execution, in milliseconds (ms). Here it is 10 minutes. storage: type: hdfs # The storage type is declared as HDFS here, and the actual storage is in the S3 below. max-retained: 3 # Maximum number of Checkpoint histories to retain. Old Checkpoints will be automatically deleted to save space. plugin-config: storage.type: s3 # The actual configured storage type is S3 (or object storage compatible with S3 protocol such as MinIO) fs.s3a.access.key: xxxxxxx # Access Key of S3-compatible storage fs.s3a.secret.key: xxxxxxx # Secret Key of S3-compatible storage fs.s3a.endpoint: http://xxxxxxxx:8060 # Service endpoint (Endpoint) address of S3-compatible storage s3.bucket: s3a://seatunel-pro-bucket # Name of the bucket used to store Checkpoint data fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider # Authentication credential provider # Observability configuration telemetry: metric: enabled: true # Enable metric collection logs: # Enable scheduled log deletion: Enable the automatic cleaning function of log files to prevent logs from filling up the disk. scheduled-deletion-enable: true # Web UI and REST API configuration http: enable-http: true # Enable Web UI and HTTP REST API services port: 8080 # Port number bound by the Web service enable-dynamic-port: false # Disable dynamic ports. Whether to enable other ports if 8080 is occupied. # The following is the Web UI basic authentication configuration enable-basic-auth: true # Enable basic identity authentication basic-auth-username: admin # Login username basic-auth-password: xxxxxxx # Login password This JVM parameter configuration file is mainly used to ensure the stability and performance of the SeaTunnel engine during large-scale data processing. It provides basic memory guarantee by setting the heap memory and metaspace capacity, and conducts a series of optimizations specifically for the G1 garbage collector to effectively manage memory garbage, control garbage collection pause time, and improve operating efficiency. jvm_master_options # JVM heap memory -Xms30g -Xmx30g # Memory overflow diagnosis: Automatically generate a Heap Dump file when OOM occurs, and save it to the specified path for subsequent analysis. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/seatunnel/dump/zeta-server # Metaspace: Limit the maximum capacity to 5GB to prevent metadata from expanding infinitely and occupying too much local memory. -XX:MaxMetaspaceSize=5g # G1 garbage collector related configuration -XX:+UseG1GC # Enable G1 garbage collector -XX:+PrintGCDetails # Print detailed GC information in the log -Xloggc:/path/to/gc.log # Output GC logs to the specified file -XX:+PrintGCDateStamps # Print timestamps in GC logs -XX:MaxGCPauseMillis=5000 # The target maximum GC pause time is 5000 milliseconds (5 seconds) -XX:InitiatingHeapOccupancyPercent=50 # Start concurrent GC cycle when heap memory usage reaches 50% -XX:+UseStringDeduplication # Enable string deduplication to save memory space -XX:GCTimeRatio=4 # Set the target ratio of GC time to application time -XX:G1ReservePercent=15 # Reserve 15% of heap memory -XX:ConcGCThreads=6 # Set the number of threads used in the concurrent GC phase to 6 -XX:G1HeapRegionSize=32m # Set the G1 region size to 32MB This configuration file defines the underlying distributed architecture and collaboration mechanism of the SeaTunnel engine cluster. It is mainly used to establish and manage network communication between cluster nodes. The configuration also includes a high-precision failure detection heartbeat mechanism to ensure that node failure problems can be quickly detected and handled, ensuring the high availability of the cluster. At the same time, it enables distributed data persistence based on S3-compatible storage, reliably saving key state information to object storage. hazelcast-master.yaml (iMap stored in self-built object storage) hazelcast: cluster-name: seatunnel # Cluster name, which must be consistent across all nodes network: rest-api: enabled: true # Enable REST API endpoint-groups: CLUSTER_WRITE: enabled: true DATA: enabled: true join: tcp-ip: enabled: true # Use TCP/IP discovery mechanism member-list: # Cluster node list - 10.xx.xx.xxx:5801 - 10.xx.xx.xxx:5801 - 10.xx.xx.xxx:5802 - 10.xx.xx.xxx:5802 - 10.xx.xx.xxx:5802 port: auto-increment: false # Disable port auto-increment port: 5801 # Fixed port 5801 properties: hazelcast.invocation.max.retry.count: 20 # Maximum number of invocation retries hazelcast.tcp.join.port.try.count: 30 # Number of TCP connection port attempts hazelcast.logging.type: log4j2 # Use log4j2 logging framework hazelcast.operation.generic.thread.count: 50 # Number of generic operation threads hazelcast.heartbeat.failuredetector.type: phi-accrual # Use Phi-accrual failure detector hazelcast.heartbeat.interval.seconds: 2 # Heartbeat interval (seconds) hazelcast.max.no.heartbeat.seconds: 180 # No heartbeat timeout (seconds) hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 # Failure detection threshold hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 # Detection sample size hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100 # Minimum standard deviation (milliseconds) hazelcast.operation.call.timeout.millis: 150000 # Operation call timeout (milliseconds) map: engine*: map-store: enabled: true # Enable Map storage persistence initial-mode: EAGER # Load all data immediately at startup factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory # Persistence factory class properties: type: hdfs # Storage type namespace: /seatunnel/imap # Namespace path clusterName: seatunnel-cluster # Cluster name storage.type: s3 # Actually use S3-compatible storage fs.s3a.access.key: xxxxxxxxxxxxxxxx # S3 access key fs.s3a.secret.key: xxxxxxxxxxxxxxxx # S3 secret key fs.s3a.endpoint: http://xxxxxxx:8060 # S3 endpoint address s3.bucket: s3a://seatunel-pro-bucket # S3 storage bucket name fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider # Authentication provider 3) Exemples de tasques de col·lecció ① MySQL-CDC to StarRocks Per recollir les dades de MySQL-CDC, és necessari assegurar-se que la base de dades font ha habilitat Binlog amb el format de ROW, l'usuari té els permisos pertinents i el paquet corresponent de MySQL Jar es col·loca a la base de dades. Per a més informació, si us plau, visiteu el web oficial: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC El següent és una configuració de mostra per a la nostra col·lecció de MySQL-CDC. env { parallelism = 1 # Parallelism is set to 1; only 1 is allowed for streaming collection job.mode = "STREAMING" # Streaming job mode job.name = cdh2sr # Job name identifier job.retry.times = 3 # Number of retries if the job fails job.retry.interval.seconds=180 # Retry interval (in seconds) } source { MySQL-CDC { base-url = "jdbc:mysql://xxxxxxx:3306/databasename" # MySQL connection address username = "xxxxxxr" # Database username password = "xxxxxx" # Database password table-names = ["databasename.table1","databasename_pro.table2"] # List of tables to sync (format: database.table name) startup.mode = "latest" # Start syncing from the latest position exactly_once = true # Enable Exactly-Once semantics debezium { include.schema.changes = "false" # Exclude schema changes snapshot.mode = when_needed # Take snapshots on demand } } } transform { TableRename { plugin_input = "cdc" # Input plugin identifier plugin_output = "rs" # Output plugin identifier convert_case = "LOWER" # Convert table names to lowercase prefix = "ods_cdh_databasename_" # Add prefix to table names } } sink { StarRocks { plugin_input = "rs" # Input plugin identifier (consistent with transform output) nodeUrls = ["xxxxxxx:8030","xxxxxxx:8030","xxxxxxx:8030"] # StarRocks FE node addresses base-url = "jdbc:mysql://xxxxxxx:3307" # StarRocks MySQL protocol address username = "xxxx" # StarRocks username password ="xxxxxxx" # StarRocks password database = "ods" # Target database enable_upsert_delete = true # Enable update/delete functionality max_retries = 3 # Number of retries if write fails http_socket_timeout_ms = 360000 # HTTP timeout (in milliseconds) retry_backoff_multiplier_ms = 2000 # Retry backoff multiplier max_retry_backoff_ms = 20000 # Maximum retry backoff time batch_max_rows = 2048 # Maximum number of rows per batch batch_max_bytes = 50000000 # Maximum bytes per batch } } ② Oracle-CDC to StarRocks Per recollir dades d'Oracle-CDC, assegureu-vos que la base de dades font té Logminer habilitat, l'usuari té els permisos pertinents, i col·loqueu els paquets corresponents OJDBC.Jar i Orai18n.jar en el Per a més detalls, consulteu el web oficial: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC En particular, pel que fa als problemes de latència que s'enfronten durant la recollida d'Oracle-CDC, recomanem que pregunti primer a la DBA per comprovar la freqüència amb què es canvien els registres de logminer. La recomanació oficial és mantenir-los al voltant de 10 vegades per hora, ja que un canvi massa freqüent pot causar una latència prolongada. Si la freqüència és massa alta, augmenteu la mida dels arxius de registre individuals. -- Query log switch frequency SELECT GROUP#, THREAD#, BYTES/1024/1024 || 'MB' "SIZE", ARCHIVED, STATUS FROM V$LOG; SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour, COUNT(*) AS switch_count FROM v$log_history WHERE first_time >= TRUNC(SYSDATE) - 1 -- Data from the past day GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24') ORDER BY hour; -- Query log file size SELECT F.MEMBER, L.GROUP#, L.THREAD#, L.SEQUENCE#, L.BYTES/1024/1024 AS SIZE_MB, L.ARCHIVED, L.STATUS, L.FIRST_CHANGE#, L.NEXT_CHANGE# FROM V$LOG L, V$LOGFILE F WHERE F.GROUP# = L.GROUP# ORDER BY L.GROUP#; El següent és una configuració de mostra per a la nostra col·lecció Oracle-CDC. env { parallelism = 1 # Parallelism is 1; only 1 is allowed for streaming collection job.mode = "STREAMING" # Streaming job mode job.name = bpm2sr # Job name identifier job.retry.times = 3 # Number of retries if the job fails job.retry.interval.seconds=180 # Retry interval (in seconds) } source { Oracle-CDC { plugin_output = "cdc" # Output plugin identifier base-url = "jdbc:oracle:thin:@xxxxxx:1521:DB" # Oracle connection address username = "xxxxxx" # Database username password = "xxxxxx" # Database password table-names = ["DB.SC.TABLE1","DB.SC.TABLE2"] # Tables to sync (format: database.schema.table name) startup.mode = "latest" # Start syncing from the latest position database-names = ["DB"] # Database name schema-names = ["SC"] # Schema name skip_analyze = true # Skip table analysis use_select_count = true # Use statistics exactly_once = true # Enable Exactly-Once semantics connection.pool.size = 20 # Connection pool size debezium { log.mining.strategy = "online_catalog" # Log mining strategy log.mining.continuous.mine = true # Continuously mine logs lob.enabled = false # Disable LOB support internal.log.mining.dml.parser ="legacy" # Use legacy DML parser } } } transform { TableRename { plugin_input = "cdc" # Input plugin identifier plugin_output = "rs" # Output plugin identifier convert_case = "LOWER" # Convert table names to lowercase prefix = "ods_crm_db_" # Add prefix to table names } } sink { StarRocks { plugin_input = "rs" # Input plugin identifier nodeUrls = ["xxxxxxx:8030","xxxxxxx:8030","xxxxxxx:8030"] # StarRocks FE nodes base-url = "jdbc:mysql://xxxxxxx:3307" # JDBC connection address username = "xxxx" # Username password ="xxxxxxx" # Password database = "ods" # Target database enable_upsert_delete = true # Enable update/delete max_retries = 3 # Maximum number of retries http_socket_timeout_ms = 360000 # HTTP timeout retry_backoff_multiplier_ms = 2000 # Retry backoff multiplier max_retry_backoff_ms = 20000 # Maximum retry backoff time batch_max_rows = 2048 # Maximum rows per batch batch_max_bytes = 50000000 # Maximum bytes per batch } } 4) Monitorització observable Gràcies a les potents mètriques de monitoratge proporcionades per la nova versió de SeaTunnel i el sistema de monitoratge complet que hem construït, podem entendre plenament l'estat de la plataforma de recollida de dades des de la perspectiva de tot el clúster i el nivell de tasques. ① Cluster Monitoring Estat de nodes: Monitorització en temps real del nombre de nodes de clúster i el seu estat de supervivència per assegurar que no hi hagi nodes de Worker fora de línia anormals i garantir les capacitats de processament de clúster. Permeabilitat de clúster: Monitoritzar el SourceReceivedQPS i SinkWriteQPS global del clúster per captar les taxes globals d'entrada i sortida de dades i avaluar la càrrega del clúster. Estat de recursos: Monitoritzar la CPU i la memòria dels nodes de clúster per proporcionar una base per a l'expansió o l'optimització dels recursos. Salut de la xarxa: Assegurar bones condicions de xarxa de clústers mitjançant el seguiment del batec cardíac intern i la latència de la comunicació. ② Task Monitoring Estat d'operació de les tasques: la comprovació en temps real de l'estat d'execució (Executat / Fracassat / Acabat) de totes les tasques és el requisit més bàsic de monitoratge. Volum de sincronització de dades: Monitoritza el SourceReceivedCount i el SinkWriteCount de cada tasca per captar el rendiment de cada canonada de dades en temps real. Temps de latència: Aquest és un dels indicadors més crítics per a les tasques del CDC. S'envien alertes quan es produeix una latència contínua al final de la recollida. Resultats: beneficis mesurables Després d'un període d'operació estable, el marc de recopilació de dades de nova generació basat en Apache SeaTunnel ens ha aportat beneficis significatius i quantificables, principalment reflectits en els següents aspectes: (1) Estabilitat: De "Foc constant" a "Pau de la ment" : Under the old solution, 1-3 synchronization abnormalities needed to be handled per month. Since the new cluster was launched, core data synchronization tasks have maintained 0 failures, with no data service interruptions caused by the framework itself. Task failure rate reduced by over 99% : Relying on Apache SeaTunnel's Exactly-Once semantics and powerful Checkpoint mechanism, end-to-end Exactly-Once processing is achieved, completely solving the problem of potential trace data duplication or loss and fundamentally ensuring data quality. 100% data consistency : The high-availability design of the cluster ensures 99.99% service availability. Any single-point failure can be automatically recovered within minutes, with no impact on business operations. Significantly improved availability (2) Eficiència: Desenvolupament duplicat i eficiència O&M : From writing and maintaining multiple sets of scripts in the past to unified configuration-based development. The time to connect new data sources has been reduced from 1-2 person-days to within 1 minute, showing a significant efficiency improvement. 50% improvement in development efficiency : Now, the overall status can be monitored through the Grafana dashboard, with daily active O&M investment of less than 0.5 person-hours. 70% reduction in O&M costs : End-to-end data latency has been optimized from minutes to seconds, providing a solid foundation for real-time data analysis and decision-making. Optimized data timeliness Arquitectura: optimització de recursos i marc unificat : Successfully integrated multiple technology stacks such as Sqoop and StreamSets into Apache SeaTunnel, greatly reducing technical complexity and long-term maintenance costs. Unified technology stack Perspectives: plans de futur : We will actively explore the native deployment and scheduling capabilities of Apache SeaTunnel on Kubernetes, leveraging its elastic scaling features to achieve on-demand allocation of computing resources, further optimizing costs and efficiency, and better embracing hybrid cloud and multi-cloud strategies. (1) Full cloud native adoption : Build AIOps capabilities based on the rich Metrics data collected, realizing intelligent prediction of task performance, automatic root cause analysis of faults, and intelligent parameter tuning. (2) Intelligent O&M 6 Reconeixement En aquest sentit, agraïm sincerament a la comunitat de codi obert d'Apache SeaTunnel.Al mateix temps, també agraïm a tots els membres de l'equip de projectes interns de l'empresa - el vostre treball dur i el coratge d'explorar són les claus per a la implementació reeixida d'aquesta actualització d'arquitectura. SUPCON va descarregar eines de dades de silo per a Apache SeaTunnel - ara les tasques de sincronització del nucli s'executen amb 0 fallades! 99% menys fallades, 100% de consistència, 70% menys costos d'O&M. Gràcies a @ApacheSeaTunnel! #DataEngineering #OpenSource
